Apple II
Technical Notes
_____________________________________________________________________________
                                                  Developer Technical Support


UniDisk 3.5
#5:    Architectural Differences Between 3.5" Drives

Revised by:    Matt Deatherage                                  November 1988
Written by:    Cameron Birse & Mike Askins                       October 1986

This Technical Note provides information of interest to those developers 
writing low-level software for the UniDisk 3.5 and Apple 3.5 disk drives.
_____________________________________________________________________________

Definition of Drives

It is important to understand the differences between Apple's 3.5" drives if 
you are considering writing low-level software for use on the Apple II family 
drives.

UniDisk 3.5        is an intelligent drive, meaning that it has a 
                   microprocessor-based controller inside the drive enclosure 
                   that communicates with the host computer in an intelligent 
                   fashion through the IWM port.  The host sends commands to 
                   the intelligent controller in the drive and the controller 
                   manipulates the drive hardware to read or write, and sends 
                   the data back to the host in a "packet" format.

Apple 3.5 Drive    is an unintelligent drive that depends on the host 
                   computer to manipulate the drive hardware to read and write 
                   data to and from the drive.  Apple IIGS low-level routines 
                   for this drive will be essentially the same as those 
                   downloaded to the UniDisk 3.5 controller RAM, except they 
                   will reside in the host computer's memory.  New device-
                   specific control calls must be used for the Apple 3.5 Drive.


Tips for Low-Level Drive Access

The following calls are not guaranteed to be compatible in the future; for the 
highest level of compatibility, avoid disk access at this level.

o    Identifying the drives:  The drives can be identified by first 
     searching for a device that has the SmartPort firmware.  After 
     determining that there is a SmartPort device in the machine, 
     perform a STATUS call with the statcode = $03 (return Device 
     Information Block (DIB)).  In the DIB there is a type byte and a 
     subtype byte.  The UniDisk 3.5 has a value of $01 for the type 
     byte and $00 for the subtype byte.  The Apple 3.5 Drive also has a 
     value of $01 for the type byte, but its subtype byte value is $C0.  
     Be sure to make device-specific calls to ensure drive 
     identification.  See SmartPort Technical Note #7, SmartPort 
     Subtype Codes for more details.
o    Special routines:  In the UniDisk 3.5, there is extra RAM space 
     in the controller's memory map for custom read, write and ID 
     routines.  These routines can be downloaded to the controller from 
     the host and executed via the SmartPort.  With the Apple 3.5 
     Drive, these special routines reside in the host memory.  
     Equivalent mark and hook tables for the Apple 3.5 Drive, set by 
     control calls through the SmartPort, are supported on the Apple 
     IIGS , but are not guaranteed for all drives and CPUs.
o    IWM hardware differences:  On the UniDisk 3.5, the IWM 
     registers are located in the drive's controller memory starting at 
     $0A00.  On the Apple 3.5 Drive, the IWM registers are located in 
     host memory starting at $C0E0 (slot 6 I/O space).
o    Speed differences:  Downloaded code in the UniDisk 3.5 
     controller runs at slightly under 2 MHz, and the cycle times are 
     regular.  The Apple IIGS running at 1 MHz also has regular cycles, 
     however, when running at 2.8 MHz, the timing is complicated by RAM 
     refresh and I/O synchronization times.  It is best to avoid timing 
     critical solutions, or be sure to run at 1 MHz for the Apple 3.5 
     Drive.

As always, in order to promote compatibility between your software and future 
Apple II systems and to avoid writing utilities which will only work on one 
kind of drive, you should avoid low-level calls that are specific to a 
particular device or CPU.


Further Reference
o    Apple IIGS Firmware Reference

